Wireless Broadband networks, such those defined by EDGE, GPRS, EVDO, EVDV, UMTS and others, have given little attention to requirements posed by applications whose functions are based on actions initiated autonomously by the device, application or service, in contrast to functions initiated by the. Such applications include, for example, email, instant messaging, visual voicemail and voice and video telephony, and others. Such applications typically require an always-on IP connection and frequent transmit of small bits of data. Wireless Broadband networks are designed and optimized for high-throughput of large amounts of data, not for applications that require frequent, but low-throughput and/or small amounts of data.
Each transaction puts the mobile device radio in a high power mode for considerable length of time—typically between 15-30 seconds. As the high power mode can consume as much as 100× the power as an idle mode, these autonomously initiated applications quickly drain battery in Wireless Broadband networks. The issue has been further exacerbated by the rapid increase of popularity of applications with autonomously-initiated functionalities, such as mobile gaming, social media, news feeds, streaming video and audio, and others which may require an always-on of frequent IP connections and frequent transmit of small bits of data.
As such, mobile applications have changed the needs of caching, transport and content management. Traditional caching strategies are no longer suitable as when wireless standards were specified, there was little attention to requirements posed by applications whose functions are based on actions initiated by the network, compared to functions initiated by the user or by the device.
However, applications (e.g., mobile applications or mobile clients) communicate with their respective host servers using a variety of types of polling patterns which need to be taken into account for effective caching. For example, in a persistent IP connection, such as one established by long polling or COMET style push, a web application maintains a long-held request (e.g., long-held HTTP requests) which allows the host server to push data to the client when this data becomes available. The persistent connection allows emulation of content push from server to client (e.g., mobile client). Specifically, when a response is not available when the request is sent, the server can hold the request until information becomes available to be sent to the client. The client then re-issues a request to the server, which the server then responds to or holds until a response is available.
This model may be accompanied with some failover mechanism that allows client to detect dropped connection and reestablish it when required (e.g., due to socket timeouts). Long polling behavior or other types of requests with a persistent connection (e.g., HTTP streaming) is different other types of constant polling where the request is not held or other more complex types of polling patterns and thus changes the requirements or parameters associated with caching content received over long polls.